Every plant has a story like this by now. Someone on the manufacturing engineering team got frustrated with a paper travel router or an Excel-based changeover checklist, downloaded a trial of Tulip or built something in Ignition Perspective over a weekend, and within a month had replaced a genuinely bad process with something operators actually liked using. Leadership noticed. Other departments noticed. And now, a year or two later, that plant has two dozen low-code apps built by six different people, none of which talk to each other, three of which duplicate the same data entry, and at least one that’s quietly become load-bearing for a quality record nobody thought to make auditable.
This is not a failure of low-code tooling. Tulip, Ignition Perspective, FactoryTalk Optix, and the Mendix-based apps coming out of Siemens’s ecosystem are all doing exactly what they were built to do: let people close to the problem build software fast, without waiting eighteen months for an MES vendor’s professional services team. The failure is organizational. Nobody decided, up front, what kind of workflow belongs in a citizen-developer app and what kind belongs in the governed core of the MES. So now IT and manufacturing engineering are doing that triage after the fact, which is always more painful than doing it first.
The real question isn’t “low-code or MES” — it’s “which workflows deserve which”
The industry conversation tends to frame this as a platform choice, as if you pick a lane and stay in it. That’s the wrong mental model. A modern manufacturing software stack should have both: a governed core MES handling the things that must be consistent, auditable, and structurally connected to ERP and quality systems, and a layer of low-code apps handling the things that are local, fast-changing, and don’t need to be enterprise infrastructure. The skill isn’t choosing a platform. It’s sorting workflows correctly and then keeping them sorted as the app catalog grows.
Three factors do most of the sorting work: how often the workflow changes, whether it needs to be reused across lines or sites, and how deep the audit and traceability requirement actually is.
Change frequency
If a workflow gets tweaked every few weeks — a new inspection point added because of a customer complaint, a changed torque sequence, a new operator prompt because of a near-miss — that’s a strong signal for low-code. Core MES modules typically run through change control processes, validation cycles, and IT release schedules that make a two-week iteration cycle painful, sometimes impossible in regulated environments. A citizen developer who can push an updated Perspective screen or Tulip app the same afternoon a process changes is delivering real value that a formal MES change request can’t match. Conversely, if a workflow has been stable for years and only changes when the product line itself changes, the flexibility of low-code buys you nothing and you’re better off with something governed and stable.
Cross-line and cross-site reuse
This is the factor teams underweight the most. An app built by one engineer for one line, solving one line’s problem, is a fine low-code candidate even if it touches production data. But the moment three lines want the same changeover checklist, or two plants want the same non-conformance workflow, you’ve crossed into territory where inconsistent local implementations become a real liability. Every line running its own slightly different version of “the same” app is how you end up with incomparable OEE definitions, inconsistent scrap coding, and a data model that nobody can roll up cleanly at the enterprise level. Widely reused workflows belong in a managed, versioned module — whether that’s a core MES function or a low-code app that IT has adopted into the official catalog with real version control — not in six independently maintained copies.
Audit and traceability depth
This is the one that creates legal and quality exposure if you get it wrong. A workflow that needs an electronic signature, a tamper-evident record, genealogy linking a component lot to a finished unit, or anything that could end up in front of a regulator or an auditor needs to live in a system built for that from the ground up — with proper user authentication, record retention, and audit trails as core architecture, not bolted on. Some low-code platforms have matured real capability here, and it’s worth evaluating case by case rather than assuming a citizen-developer tool can never carry regulated data. But the default assumption should run the other way: if the workflow is truly audit-critical, treat that as a strong pull toward the governed core, and require anyone proposing otherwise to make the case.
Score it before you build it
A workable practice is to score any proposed new digital workflow across those three dimensions before anyone opens a low-code editor. High change frequency, single-line scope, low audit depth — build it as a local app, fast, and don’t apologize for it being disposable. Low change frequency, multi-line reuse, high audit depth — that’s core MES territory, full stop. Most real requests land in between, and that’s where judgment and a governance conversation matter, not a rigid scorecard.
Avoiding the sprawl, the second time around
For plants already past the first successful pilot and staring at an unmanaged app catalog, retroactive governance is uncomfortable but necessary. A few things actually work:
- Inventory everything first. Most manufacturing engineering leaders are surprised by how many apps exist once they actually go count, because low-code adoption spreads department to department without anyone centrally tracking it.
- Classify existing apps against the same three factors used for new requests, rather than grandfathering everything in because it’s already running in production.
- Establish one integration pattern — typically OPC UA or MQTT with Sparkplug B for equipment data, and a defined API contract for anything touching MES or ERP — so low-code apps aren’t each inventing their own connectivity approach to the historian or the PLC.
- Put a real owner on the app catalog, usually a joint role between manufacturing engineering and plant IT, with authority to retire duplicate apps and promote genuinely reusable ones into managed status.
- Set a review cadence tied to the same change-frequency logic: apps built for volatile local processes get lighter-touch review; anything feeding a quality or compliance record gets treated with the same rigor as a core MES change.
None of this argues against low-code tooling — the category has earned its place on the shop floor by solving problems that a decade of monolithic MES rollouts never solved fast enough. The argument is against treating it as a free pass to skip the governance work manufacturing IT has always had to do. The plants getting real, durable value out of Tulip, Ignition Perspective, FactoryTalk Optix, and similar tools aren’t the ones with the most apps. They’re the ones who decided early — or are deciding now, later than they’d like — exactly which problems those apps are allowed to own.
This article was written with the assistance of artificial intelligence. While we aim for accuracy, the information may be incomplete, out of date, or incorrect, and should be independently verified before you rely on it for any decision. It is provided for general information only and does not constitute professional advice.
